Angular Static-site Generation

Many words have been written about headless Drupal. If you're unfamiliar, that is finding a non-Drupal way of handling what the end-user sees and experiences. The front-end experience.

Sometimes it feels like there are more justifications of headless Drupal sites than real-world applications of the pattern. Why is that? All of these solutions add a new layer of complexity to a system that is already quite complicated. Oftentimes, the specter of that new complexity offsets the advantage of a headless solution. So we stick with a traditional Drupal site.

That said, I humbly submit one more word to the cause: Angular.

This Javascript framework now supports static site generation in a way that makes a compelling partner to Drupal. For that, we can thank the development of Angular Universal, a component that also provides server-side rendering, as a way to boost site speed and performance.

So which is it: static-site generation or server-side rendering? In this example, we use static-site generation to create a snapshot of a Drupal site that can be deployed in any simple hosting environment.

What does that look like?

Angular Universal uses the term "prerender" to describe the implementation, but the end-result is a directory of self-contained web pages. Other tools, like Gatsby and Scully, call this static site generation.

This example goes into a full walk-through with Angular Universal.

The steps involve:

• create an Angular project with the Angular-CLI, or use an existing one, version >= 10
• add this tool to the project: "ng add @nguniversal/express-engine"
• define a list of prerender pages
• run the command to build: "npm run prerender"
• view the static files in the directory "dist/<project-name>/browser"

Who does this appeal to?

Angular is a very mature platform as of today with lots of support and learning resources. It has a native routing system -- not an add- on -- and it uses a more traditional template system. Compared to ...? React. Yes this is in contrast to React.

Developers with Javascript experience can easily adapt to this. More specifically, this will appeal to devs comfortable with Angular-style templates. React and JSX are different animals however, mainly because of the different approaches to templating.

Is templating that important? Yes. the strangest arguments for a headless Drupal system are related to front-end build and design. You plan to dedicate a lot of time building out the components and pages, so you want to use what is most comfortable for you.

If you use and enjoy React, then stick with it! If you've used a JS tool with a template system that is similar to Angular, this may be a good fit.

What about data?

Data is the biggest problem to solve with a headless Drupal site. Angular does not solve this in an easy way. It requires calling some endpoints and normalizing the data received. If the structure of your data in Drupal is very complex ... this may be the time to hit the off-ramp.

Gatsby is a very popular option for headless Drupal, if for no other reason than it has invested huge efforts in making data easily accessible via GraphQL. It can traverse Drupal entities to pull together the relevant content you need, in ways that are not possible with Drupal tools like REST. But learning GraphQL and working that into your development process for the first time brings its owns challenges.

What is to gain from headless?

As I mentioned at the start, the promise of a headless Drupal system may seem stronger than the payout. The added complexity of supporting two systems is a major hurdle to this pattern.

But if we add a front-end that is simple enough, there are advantages to be gained.

1. Speed: static sites offer much better page speed than a traditional LAMP-stack site.
2. Security and simplicity: with no database or PHP integration, a static platform requires less to build and maintain.
3. Developer cost: building pages in Drupal can be a complicated affair without the relevant experience. If you have a background with Javascript tools, let's use that!

There are many ways to solve this, so pick what fits with your experience, comfort level and needs.